Closes #6425

Why is this the best possible solution? Were any other approaches considered?

The core problem is that there is no authoritative "entity list vs. plain CSV" signal that survives to parse time. The only authoritative signal (type=entityList in the OpenRosa manifest) exists at
download time. At parse time, both look identical with the same jr://file-csv/<name>.csv reference, same on-disk CSV - so the fix has to manufacture a reliable discriminator that lives until parsing.

Chosen approach:

Two changes that together make file presence in the form's media directory the discriminator between a plain CSV and an entity list:

1. isSupported defers to the attached file. LocalEntitiesInstanceProvider now returns false when the instance's src resolves to a media file that exists on disk, letting JavaRosa serve the attached CSV;
   Otherwise, it serves the entity list from the DB.

   if (mediaFileRepository.get(instanceSrc)?.exists() == true) {                                                                                                                                                         
       return false                                                                                                                                                                                                      
   }                                                                                                                                                                                                                     
   return createDataAdapter().supportsInstance(instanceId)                                                                                                                                                               

2. Entity-list seeds are no longer persisted. After import into the DB, the temp CSV is deleted (tempMediaFile.delete()). This is safe because every entity read is DB-backed, so the seed file is redundant - and with it gone, a CSV in the media dir can only be a genuine attachment.

Other approaches considered:

• Compare the attachment hash to the entity list's stored hash, if it equals it is an entity file - rejected: the entity list's manifest hash is derived from the dataset's last-updated timestamp, not the CSV content, so it never reliably matches a file's content hash.
• Derive entity-ness from the form definition (in JavaRosa) - not possible: isSupported only gets the instance id and raw src, which is identical for a CSV and an entity list; JavaRosa has no entity awareness.
• A per-form marker file/database listing entity-list attachments - a workable fallback, only needed if seeds had to stay on disk. Once we confirmed entity reads are fully DB-backed, file presence alone is a cleaner
  discriminator.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

When a form attaches a static CSV whose name matches an entity list in the project, the attached CSV is now used instead of the entity list (#6425). Genuine entity-list forms are unaffected and keep loading from the DB.

The change touches how external instances are resolved and stops persisting entity-list seed CSVs in the media directory, so testing should focus on entity data loading being correct across the different form scenarios:

• forms using entity lists only,
• forms using entity lists + attached CSVs (including same-named collisions),
• plain forms with attached CSVs.

Do we need any specific form for testing your changes? If so, please attach one.

The one linked in the issue for reproducing the bug.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No.

Before submitting this PR, please make sure you have:

• added or modified tests for any new or changed behavior
• run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
• added a comment above any new strings describing it for translators
• added any new strings with date formatting to DateFormatsTest
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines